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Abstract. Knowledge-based systems are suitable for realizing advanced functions that re- 
Q |' quire domain-specific expert knowledge, while knowledge representation languages and their 

D , supporting environments are essential for realizing such systems. Although Prolog is use- 

• ful and effective in realizing such a supporting environment, the language interoperability 

with other implementation languages, such as Java, is often an important issue in practical 
application development. This paper describes the techniques for translating a knowledge 
representation language that is a nondeterministic functional language based on attribute 
l_J \ grammars into Java. The translation is based on binarization and the techniques proposed 

■ for Prolog to Java translation although the semantics are different from those of Prolog. 

^ ' A continuation unit is introduced to handle continuation efficiently, while the variable and 

register management on backtracking is simplified by using the single and unidirectional 
assignment features of variables. An experimental translator written in the language itself 
successfully generates Java code, while experimental results show that the generated code 
is over 25 times faster than that of Prolog Cafe for nondeterministic programs, and over 2 
qq ■ times faster for deterministic programs. The generated code is also over 2 times faster than 

£f*l ' B-Prolog for nondeterministic programs. 
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1 Introduction 

There is high demand for advanced information services in various application domains such as 
medical services and supply-chain management, as information and communication technology 
penetrates deeply into our society. Clinical decision support [1,2] to prevent medical errors and 
order placement support for optimal inventory management [3] are typical examples. It is, however, 
not prudent to implement such functions as a normal part of the traditional information system 
using conventional programming languages. This is because expert knowledge is often large scale 
and complicated, and each application domain typically has its own specific structures and se- 
mantics. Therefore, not only the analysis, but also the description, audit, and maintenance of such 
knowledge are often difficult without expertise in the application domain. It is thus, essential to 
realize such advanced functions to allow domain experts themselves to describe, audit, and main- 
tain their knowledge. A knowledge-based system approach is suitable for such purposes because a 
suitable framework for representing and managing expert knowledge is supplied. 

Previously, Nagasawa et al. proposed the knowledge representation language DSP [4, 5] and 
its supporting environment. DSP is a nondeterministic functional language based on attribute 
grammars [6, 7] and is suitable for representing complex search problems without relying on any 
side effects. The supporting environment has been developed on top of an integrated development 
environment called Inside Prolog [8]. Inside Prolog provides standard Prolog functionality, con- 
forming to ISO/IEC 13211-1 [9], and also a large variety of Application Programming Interfaces 
(APIs) that are essential for practical application development and multi-thread capability for 
enterprise use [10]. 

These features allow the consistent development of knowledge-based systems from prototypes 
to practical systems for both stand-alone and enterprise use [11]. Such systems have been applied 
to several practical applications, and the effectiveness thereof has been clarified. However, several 
issues have also been perceived from these experiences. One is the complexity of combining a 



Prolog-based system with a system written in a normal procedural language, such as Java. The 
other is the adaptability to a new computer environment such as mobile devices. 

This paper describes the implementation techniques required to translate a nondcterministic 
functional language based on attribute grammars into a procedural language such as Java. The 
proposed techniques are based on the techniques for Prolog to Java translation. Section 2 gives an 
overview of the knowledge representation language DSP, and clarifies how it differs from Prolog. 
In Section 3, the translation techniques for logic programming languages are briefly reviewed, 
and basic ideas useful for the translation of DSP identified. Section 4 discusses the program 
representations of DSP in Java, while Section 5 evaluates the performance using an experimental 
translator. 

2 Overview of Knowledge Representation Language DSP 

2.1 Background 

It is essential to formally analyze, systematize, and describe the knowledge of an application 
domain in the development of a knowledge-based system. The description of knowledge is concep- 
tually possible in any conventional programming language. Nevertheless, it is difficult to describe, 
audit, and maintain a knowledge base using a procedural language such as Java. This is because 
the knowledge of an application domain is often large scale and complicated, and each application 
domain has its own specific structures and semantics. In particular, the audit and maintenance of 
written knowledge is a major issue in an information system involving expert knowledge, because 
such a system is very often stiffened and the transfer of expert knowledge to succeeding gener- 
ations is difficult [12]. Therefore, it is very important to provide a framework to enable domain 
experts themselves to describe, audit, and maintain their knowledge included in an information 
system [13]. It is perceived that a description language that is specific to an application domain 
and is designed so as to be described by domain experts is superior in terms of the minimality, con- 
structibility, comprehensibility, extensibility, and formality of the language [14]. For this reason, 
Prolog cannot be considered as a candidate for a knowledge representation language. 

DSP is a knowledge representation language based on nondeterministic attribute grammars. It 
is a functional language with a search capability using the generate and test method. Because the 
language is capable of representing trial and error without any side-effects or loop constructs, and 
the knowledge descriptions can be declaratively read and understood, it is suitable for representing 
domain-specific expert knowledge involving search problems. 

2.2 Syntax and Semantics of DSP 

A program unit to represent knowledge in DSP is called a "module" , and it represents a non- 
deterministic function involving no side-effects. Inherited attributes, synthesized attributes, and 
tentative variables for the convenience of program description, all of which are called variables, 
follow the single assignment rule and the assignment is unidirectional. Therefore, the computation 
process of a module can be represented as non-cyclic dependencies between variables. 

Table 1 shows some typical statements in the language. In this table, the types, generator, 
calculator, and tester, are functional classifications in the generate and test method. Generators 
for(B,E,S) and select(L) are provided as primitives for the convenience of knowledge repre- 
sentation although they can be defined as modules using the nondeterministic features of the 
language. Both call (M, 1,0) and dcall(M,I,0) are used for module decomposition, with the 
latter restricting the first solution of a module call like once/1 in Prolog 3 , while the former calls 
a module nondetcrministically. Calculator find(M,I,0L) collects all outputs of a module and re- 
turns a list thereof. Testers when(C) and test (C) are used to represent decomposition conditions. 
Both behaves in the same way in normal execution mode , although the former is intended to 

3 dcall stands for deterministic call. 

4 Failures of when(C) and test(C) are treated differently in debugging mode because of their semantic 
differences. 



Table 1. Typical statements in the DSP language 



Type 


Statement 


Function 


generator 


for(B,E,S) 


Assume a numeric value from B to E with step S 


generator 


select (L) 


Assume one of the elements of a list L 


generator 


call(M,I,0) 


Call a module M nondeterministically with inputs I and 






outputs O 


calculator 


dcall(M,I,0) 


Call a module M deterministically with inputs I and out- 






puts 


calculator 


find(M,I,0L) 


Get a list OL of all outputs of a module M with inputs I 


tester 


when(C) 


Specify the domain C of a method 


tester 


test(C) 


Specify the constraint C of a method 


tester 


verif y(C) 


Specify the verification condition C 



describe a guard of a method, while the latter describes a constraint. Tester verify (C) does not 
affect the execution of a module although it is classified as the tester. Solutions in which a verifi- 
cation condition is not satisfied are indicated as such, and these verification statuses are used to 
evaluate the inference results. 

pointlnQuarterCircle ({R : real}-, — (a) 

{X : real, Y : real}) —(b) 

method 

X : real = for(0.0, R, 1.0); —(c) 

Y : real = for(0.0, R, 1.0); —(d) 

D : real = sqrt(X~2 + Y~2) ; —(e) 

test(D =< R) ; —(f) 
end method; 
end module ; 

Fig. 1. Module pointlnQuarterCircle, which enumerates all points in a quarter circle 



Figure 1 gives the code for module pointlnQuarterCircle, which enumerates all points in a 
quarter circle with radius R. Statements (a) and (b) in Fig. 1 define the input and output variables 
of module pointlnQuarterCircle, respectively. Statements (c) and (d) assume the values of the 
variables X and Y from 1 to R with an incremental step 1. Statement (e) calculates the distance 
D between point (0,0) and point (X,Y). Statement (f) checks if point (X,Y) is within the circle 
of radius R. Module pointlnQuarterCircle runs nondeterministically for a given R, and returns 
one of all possible {X,Y} values 5 . Therefore, this module also behaves as a generator. Statements 
(c) to (f) can be listed in any order, and they are executed according to the dependencies between 
variables. Therefore, the computation process can be described as a non-cyclic data flow. Figure 
2 shows the data flow diagram for module pointlnQuarterCircle. Because no module includes 
any side-effects, the set of points returned by the module for the same input is always the same. 

Figure 3 shows an example of module for, which implements the generator primitive for. If 
multiple methods are defined in a module with some overlap in their domains specified by when, the 
module works nondeterministically, and thus a module can also be a generator. In this example, 
there is overlap between the domains specified by statements (a) and (c). 

2.3 Execution Model for DSP 

Since the variables follow the single assignment rule and the assignment is unidirectional, the 
statements are partially ordered according to the dependencies between variables. In the execution, 

5 {X,Y} represents a vector of two elements X and Y. 



(d)for(0.0,R,1.0) 



pointlnQuarterCircle 



(c)for(0.0,R,1.0) 



(e) sqrt(X A 2+Y A 2) 



D 
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(f) D =< R 
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Fig. 2. Data flow diagram of module pointlnQuarterCircle 



for({B : real, E : real, S : real},{N : real}) 
method — The fist method 

when(B =< E) ; —(a) 

N : real = B; —(b) 
end method; 

method — The second method 

when(B+S =< E) ; —(c) 
Bl : real = B+S; —(d) 
calKfor, {Bl, E, S}, {N}) ; —(e) 
end method; 
end; 

Fig. 3. Module for, which implements the generator primitive for 



the statements must be totally reordered and evaluated in this order. Although the method used 
to order the partially ordered statements totally does not affect the set of solutions, the order of 
the generators affects the order of the solutions returned from a nondeterministic module. 

The execution model for DSP can be represented in Prolog. Figure 4 illustrates an example 
of a simplified DSP interpreter in Prolog. In this interpreter, statements are represented as terms 
concatenated by ";" and it is assumed that the statements are totally ordered. Variables are 
represented using logical variables in Prolog. Actually, the development environment for DSP 
provides a compiler that translates into Prolog code, with the generated Prolog code translated 
into bytecode by the Prolog compiler in the runtime environment. 



3 Translation Techniques for Logic Programming Languages 

Prolog is a logic programming language that offers both declarative features and practical ap- 
plicability to various application domains. Many implementation techniques for Prolog and its 
family have been proposed, while abstract machines represented by the WAM (Warren's Abstract 



solve((A ; B)) :- 

solve (A) , 

solve (B) . 
solve ( call (M, In, Out)) :- 

reduce(call(M, In, Out), Body), 

solve (Body) . 
solve (dcall(M, In, Out)) :- 

reduce ( call (M, In, Out), Body), 

solve (Body) , ! . 
solve(f ind(M, In, OutList)) :- 

findalKOut, solve(M, In, Out), OutList). 
solve (when (Exp)) :- 

call (Exp) , ! . 
solve (test (Exp)) :- 

call (Exp) , ! . 
solve(V := for(B, E, S)) :- !, 

for(B, E, S, V). 
solve (V := select (L) ) :- !, 

member (V, L) . 
solve (V := Exp) :- 

V is Exp. 

Fig. 4. Simplified DSP interpreter in Prolog 



Machine) [15] have proven effective practical implementation techniques. On the other hand, few 
Prolog implementations provide practical functionality applicable to both stand-alone systems and 
cnterprise-mission-critical information systems without using other languages. Practically, Prolog 
is often combined with a conventional procedural language, such as Java, C, and C#, for use in 
practical applications. In such cases, language interoperability is an important issue. 

Language translation is one possible solution for improving the interoperability between Prolog 
and other combined languages. jProlog [16] and Prolog Cafe [17] are Prolog to Java translators 
based on binarization [18], while P# [19] is a Prolog to C# translator based on Prolog Cafe with 
concurrent extensions. The binarization with continuation passing is a useful idea for handling 
nondctcrminism simply in procedural languages. For example, the following clauses 

p(X) :- q(X, Y), r(Y) . 

q(X, X). 

r(X). 

can be represented by semantically equivalent clauses that take a continuation goal Cont as the 
last parameter: 

p(X, Cont) :- q(X, Y, r(Y, Cont)). 
q(X, X, Cont) :- call(Cont). 
r(X, Cont) :- call(Cont). 

Once clauses have been transformed into this form, clauses composing a predicate can be translated 
into Java classes. Figure 5 gives an example of code generated by Prolog Cafe. Predicate p/2 after 
binarization is represented as a Java class called PRED_p_l, which is a subclass of class Predicate. 
The parameters of a predicate call are passed as the arguments of the constructor of a class, while 
the right hand side of a clause is expanded as method exec. 

If a predicate consists of multiple clauses as in the following predicate p/1, it may have choice 
points. 



p(X) :- q(X, Y), r(Y) . 
p(X) :- r(X) . 



public class PRED_p_l extends Predicate { 
public Term argl; 

public PRED_p_l(Term al , Predicate cont) { 
argl = al; 

this. cont = cont; /* this. cont is inherited. */ 

> 

public Predicate exec (Prolog engine) { 
engine . setBOO ; 
Term al , a2; 
Predicate pi; 
al = argl ; 

a2 = new VariableTerm(engine) ; 
pi = new PRED_r_l(a2, cont); 
return new PRED_q_2(al, a2, pi); 

> 

} 

Fig. 5. Java code generated by Prolog Cafe 



In such a case, the generated code becomes more complex than before because the choice points 
of p/1 must be handled for backtracking. Figure 6 gives an example of the generated code for 
predicate p/1 in the previous example. Each clause of a predicate is mapped to a subclass of a 
class representing the predicate. In this example, classes PRED_p_l_l and PRED_p_l_2 correspond 
to the two clauses of predicate p/1. Methods jtry and trust of the Prolog engine correspond 
to WAM instructions that manipulate stacks and choice points for backtracking. The key ideas 
in Prolog Cafe are that continuation is represented as an instance of a Java class representing a 
predicate, and the execution control including backtracking follows the WAM. The translation is 
straightforward through the WAM, while the interoperability with Java-based systems is somewhat 
improved. On the other hand, the disadvantage is the performance of the generated code. 

4 Program Representation in Java and Inference Engine 

This section describes the translation techniques for the nondeterministic functional language DSP 
into Java based on the translation techniques for Prolog. Current implementations of the compiler 
and inference engine for DSP have been developed on top of Inside Prolog with the compiler 
generating Prolog code. Therefore, it is possible to translate this generated Prolog code into Java 
using Prolog Cafe. However, there are several differences between DSP and Prolog in terms of 
the semantics of variables and the determinism of statements. These differences allow several 
optimizations in performance, and the generated code can run faster than the code generated 
by Prolog Cafe for compatible Prolog programs. Fundamental ideas of our translation techniques 
utilize the single and unidirectional assignment features of variables and the deterministic features 
of some statements. 

The overall structure of the Java code translated from DSP provides for one module being 
mapped to a single Java class, and each method in a module mapped to a single inner class of the 
class. Figure 7 shows an example of Java code for module pointlnQuarterCircle given in Fig. 
1 . Inner classes are used to represent an execution context of a predicate as an internal state of a 
class instance. Therefore, the instances of an inner class are not declared as static unlike classes 
in Fig. 6. 

An overview of the translation process follows. First, the data flow of a module is analyzed 
for each method based on the dependencies between variables, and the statements are reordered 
according to the analysis results. Next, the statements are grouped into translation units called 



public class PRED_p_l extends Predicate { 

static Predicate _p_l_sub_l = new PRED_p_l_sub_l () ; 
static Predicate _p_l_l = new PRED_p_l_l () ; 
static Predicate _p_l_2 = new PRED_p_l_2() ; 
public Term argl; 

public Predicate exec (Prolog engine) { 
engine . aregs [1] = argl ; 
engine . cont = cont ; 
engine . setBOO ; 

return engine . jtry(_p_l_l , _p_l_sub_l) ; 

> 

} 

class PRED_p_l_sub_l extends PRED_p_l { 

public Predicate exec (Prolog engine) { 
return engine .trust (_p_l_2) ; 

> 

} 

class PRED_p_l_l extends PRED_p_l { 

public Predicate exec (Prolog engine) { 
Term al , a2 ; 
Predicate pi; 
Predicate cont; 
al = engine . aregs [1] ; 
cont = engine . cont ; 
a2 = new VariableTerm(engine) ; 
pi = new PRED_r_l(a2, cont); 
return new PRED_q_2(al, a2, pi); 

> 

} 

class PRED_p_l_2 extends PRED_p_l { 

public Predicate exec (Prolog engine) { 
Term al ; 
Predicate cont; 
al = engine . aregs [1] ; 
cont = engine . cont ; 
return new PRED_r_l(al, cont); 

} 

} 



Fig. 6. Java code with choice points generated by Prolog Cafe 



continuation units, and Java code is generated for each method according to the continuation 
units. 

4.1 Data Flow Analysis 

As described in Sect. 2, it is necessary to reorder and evaluate statements so as to fulfill variable 
dependencies since statements can be listed in any order. Therefore, partially ordered statements 
must first be totally reordered. In the reordering process, the order of the generators should be 
kept as long as the variable dependencies are satisfied, because the order of generators affects the 
order of the solutions as described in Sec. 2. On the other hand, calculators or testers can be 
moved forward for the least commitment as long as partial orders are kept. 

4.2 Continuation Unit 

If statements of a method are totally ordered, they can be divided into several groups of statements. 
Each group is called a continuation unit and consists of a series of deterministic statements, such 
as calculators and testers, followed by a single generator. It should be noted that a continuation 
unit may not contain a generator if it is the last one in a method. In the translation, a continuation 
unit is treated as a unit to translate, and is mapped to a Java class representing a continuation. 

In the example in Fig. 7, module pointlnQuarterCircle has one method, and there are three 
continuation units in the method. Inner class MethocLl corresponds to this method of the module, 
and class Method_l_cul corresponds to the continuation unit for statement (c), class Method_l_cu2 
to one for statement (d), and class Method_l_cu3 to one for statements (e) and (f), respectively 

4.3 Variable and Parameter Passing 

Although variables follow the single assignment rule like Prolog, the binding of a variable is unidi- 
rectional unlike Prolog. Therefore, it is not necessary to introduce logical variables and unification, 
unlike in Prolog Cafe. This also implies that the trail stack and variable unbinding using the stack 
are unnecessary on backtracking. Therefore, a class representing the variables is only necessary as 
a place holder for the output values of a module. Class Variable is introduced to represent such 
variables. 

Prolog Cafe uses the registers of the Prolog VM to manage the arguments of a goal. This 
approach is consistent with the WAM, but is sometimes inefficient since it requires arguments to 
be copied from/to registers to/from the stack on calls and backtracking. On the other hand, because 
the direction of variable binding is clearly defined in DSP, it is unnecessary to restore variable 
bindings on backtracking as described before. Instead, variables can always be overwritten when 
a goal is re-executed after backtracking. Therefore, input and output parameters can be passed as 
arguments of a class constructor. This simplifies the management of variables and arguments. In 
addition, as shown in Fig. 7, basic Java types, such as int and double, can be passed directly as 
inputs in some cases. This contributes to the performance improvement. 

4.4 Inference Engine 

An inference engine for the translated code is very simple because management of variables and 
registers on backtracking is unnecessary. Figure 8 shows an example of the inference engine called 
VM, which uses a stack represented as an array of interface Executable to store choice points. 
Method callO is an entry point to call the module to find an initial solution, while method 
redoO is used to find the next solution. A typical call procedure of a client program in Java is 
given below. 

VM vm = new VM() ; 

Double r = new Double (10 . 0) ; 

Variable x = new Variable (); 



public class PointlnQuarterCircle implements Executable { 
private Double r; 
private Variable x; 
private Variable y; 
private Executable cont ; 
public PointlnQuarterCircle (Double r, 

Variable x, Variable y, Executable cont) 

{ 

this.r = r; 
this.x = x; 
this.y = y; 
this. cont = cont; 



public Executable exec(VM vm) { 
return (new Method_l () ) . exec (vm) ; 

} 

public class Method_l implements Executable { 
private Variable d = new VariableO; 
private Executable method_l_cul = new Method 
private Executable method_l_cu2 = new Method 
private Executable method_l_cu3 = new Method 

public Executable exec(VM vm) { 
return method_l_cul . exec (vm) ; 

} 

class Method_l_cul implements Executable { 
public Executable exec(VM vm) { 

return new ForDouble (0 . 0, r .doubleValueO , 1.0, x, method_l_cu2) ; 

} 

} 

class Method_l_cu2 implements Executable { 
public Executable exec(VM vm) { 

return new ForDouble (0 . , r. doubleValueO , 1.0, y, method_l_cu3) ; 

} 

} 

class Method_l_cu3 implements Executable { 
public Executable exec(VM vm) { 

d . set Value (Math . sqrt (x . doubleValue ( ) *x . doubleValue ( ) + 
y . doubleValue ( ) *y . doubleValue ( ) ) ) ; 
if (! (d. doubleValueO <= r . doubleValue O ) H 
return Executable . failure ; 

} 

return cont; 

} 

} 

} 

} 

Fig. 7. Java code generated for module pointlnQuarterCircle 



_l_cul() 
_l_cu2() 
_l_cu3() 



Variable y = new VariableO; 

Executable m = new PointInQuarterCircle(r , x, y, 

Executable . success) ; 
for (boolean s = vm. call(m) ; s == true; s = vm.redoO) { 
System. out .println("X=" + x . doubleValue () + 

", Y=" + y. doubleValue () ) ; 

} 

This client program creates an inference engine, prepares output variables to receive the values of 
a solution, creates an instance of class PointlnQuarterCircle with inputs and outputs, and calls 
callO to find an initial solution. It then calls redoO to find the next one until there are no more 
solutions. 

Because the implementation of the inference engine is simple and multi-thread safe, and the 
generated classes of a module are also multi-thread safe, it is easy to deploy instances of the engine 
in a multi-thread environment. 

public class VM { 

private Executable [] choicepoint ; 

private int ccp = -1; // Current choice point. 

public VM(int initSize) { 

choicepoint = new Executable [initSize] ; 

> 

public boolean call (Executable goal) { 
while (goal != null) { 
goal = goal. exec (this) ; 
if (goal == Executable . success) { 

return true ; 
} else if (goal == Executable . failure) { 
goal = getChoicePoint () ; 

} 

} 

return false; 

} 

public boolean redoO { 

return call (getChoicePoint ()) ; 

> 

} 

Fig. 8. Inference engine for DSP 



5 Implementation and Performance Evaluation 

We have implemented the translator for DSP into Java based on the techniques proposed in Sec. 
4. The translator is written in DSP itself and generates Java code. 

Table 2 shows the performance results of 6 sample programs executed under Windows Vista 
on an Intel Corc2Duo 2.53 GHz processor with 3.0 GB memory. Java 1.6, Prolog Cafe 1.2.5, and 
B-Prolog 7.4 [20] were used in the experiments. Because the Java garbage collector affects the 
performance, 512 MB memory was statically allocated for the heap in all cases except for one 6 . 

6 About 1000 MB was allocated for the generated code for tarai w/o cuts. 



Program plan is a simple architecture design program for a parking structure. It can enumerate 
all possible column layouts for the given design conditions, such as free land space and the number 
of stories. Programs nqueens, ack, and tarai are well-known benchmarks, with ack and tarai 
using green cuts for guards in Prolog, while ack w/o cuts and tarai w/o cuts do not use cuts 
for guards. In the case of DSP, ack and tarai use dcall for self-recursive calls not to leave choice 
points, while ack w/o cuts and tarai w/o cuts use call. The programs written in DSP are 
compiled into Prolog and then compiled into bytecode. The programs are forced to backtrack in 
each iteration to enumerate all solutions, and the execution times in milliseconds are averages over 
10 trials. 

These results show that the proposed translator generates over 25 times faster code than Prolog 
Cafe, over 2 times faster code than B-Prolog, and over 5 times faster code than DSP on top of 
Inside Prolog for plan and nqueens. On the other hand, for ack and tarai the translator generates 
about 2 to 3 times faster code than Prolog Cafe, but about 5 to 15 times slower code than B- 
Prolog. The translator also generates about 8 to 13 times faster code than Prolog Cafe, but about 
4 to 10 times slower code than B-Prolog for ack w/o cuts and tarai w/o cuts. Here, plan and 
nqueens are nondctcrministic, while ack and tarai arc deterministic, ack w/o cuts and tarai 
w/o cuts are also deterministic, but they involve backtracking because of the lack of green cuts. 

These experiments indicate that the proposed translation techniques can generate faster code 
than Prolog Cafe and DSP on top of Inside Prolog for all 6 programs, and faster code than B- 
Prolog for nondctcrministic programs. In the case of deterministic programs, the advantage of the 
proposed translation techniques is obvious against Prolog Cafe if green cuts are not used in Prolog. 
The reason why these distinctive differences are observed seems to be that the simplification of the 
variable and register management for backtracking contributes to the performance improvement 
of nondeterministic programs, but it is not effective for deterministic programs with green cuts. 

In the case of B-Prolog, the execution time of tarai is almost the same as that of tarai w/o 
cuts. This is because B-Prolog compiler reduces choice points using matching trees for both tarai 
and tarai w/o cuts [21]. Although the DSP language has no explicit cut operator of Prolog, 
improving the performance by inserting cut instructions automatically in the case of exclusive 
when conditions is a future issue. 

The number of instances created during an execution has a negative impact on performance 
because of the garbage collection. Obviously, the number of instances created by the generated 
code for the proposed translation techniques is greater than that for Prolog Cafe. In the case of 
tarai w/o cuts, the generated code requires more memory than others to prevent the garbage 
collection. In the example in Fig. 7, it is clear that the number of instances can be reduced by 
merging class Method_l_cul with class MethocLl. Improving the performance by the reduction of 
instance creation is an important future issue. 



Table 2. Experimental results (in milliseconds) 



Program 


DSP on Prolog 


B-Prolog 


Prolog Cafe 


Translator 


plan 


685.0 


295.1 


2519.4 


90.5 


nqueens 


594.9 


296.2 


3279.2 


120.3 


ack 


1568.2 


52.9 


990.7 


265.0 


tarai 


1302.7 


49.4 


1680.1 


740.8 


ack w/o cuts 


2035.1 


104.7 


3421.3 


403.9 


tarai w/o cuts 


1307.8 


49.2 


6282.2 


489.5 



6 Conclusions 

This paper described the techniques for translating the nondeterministic functional language DSP 
based on attribute grammars into Java. The DSP is designed for knowledge representation of 



large scale and complicated expert knowledge in application domains. It is capable of represent- 
ing trial and error without any side-effects or loop constructs using nondeterministic features. 
Current development and runtime environments are built on top of Inside Prolog, while the run- 
time environment can be embedded in a Java-based application server. However, issues regarding 
language interoperability and adaptability to new computer environments are envisaged when ap- 
plied to practical application development. The language translation is intended to improve the 
interoperability and adaptability of DSP. 

The proposed translation techniques are based on binarization and the techniques proposed for 
the translation of Prolog. The performance, however, is improved by introducing the continuation 
unit and simplifying the management of variables and registers using the semantic differences of 
variables and explicit determinism of some statements. An experimental translator written in DSP 
itself generates Java code from DSP descriptions, and the experimental results indicate that the 
generated code is over 25 times faster than that of Prolog Cafe for nondeterministic programs, and 
over 2 times faster for deterministic programs. The generated code is also over 2 times faster than 
B-Prolog for nondeterministic programs. However, the generated code is about 3 to 15 times slower 
than B-Prolog for deterministic programs. Improving the performance of deterministic programs 
is an important future issue. 
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